Persons who are deaf or hearing impaired enough not to be able to use the telephone commonly make use of communication terminals specifically constructed and designed to enable such persons to converse over telephone lines. Such devices are referred to as telecommunication devices for the deaf or TDDs. Typically, TDDs include a keyboard and a display connected to the telephone through a modem (modulator/demodulator). The modem is built into the TDD and either directly connected to a telephone line or coupled by an acoustic coupler to a normal telephone handset. TDDs are normally capable of transmitting information over telephone lines by means of coded tones to other TDDs connected at the opposite end of the telephone line through another modem.
The code and protocol which is in widespread conventional use for TDD communication is an idiosyncratic one. The code set, known as Baudot, and the communication protocol, referred to here as Baudot/Weitbrecht, evolved historically at a time when many telecommunication devices for the deaf were based on mechanical or electromechanical devices rather than current electronic devices. Accordingly, the protocol was constructed for a set of constraints which no longer are relevant to present day devices. As it happens, those constraints worked to create a code protocol, and a telecommunication network of users and devices operating under that protocol, which is now perceived to have certain deficiencies.
One deficiency is simply speed. Conventional Baudot/Weitbrecht communication is conducted at 45.5 baud (or in some countries 50 baud). The normal Baudot character set consists of 5 bit characters. Under conventional Baudot/Weitbrecht communication, there is a start bit (one space or 0 bit), a 5 bit character, and at least 1 1/2 stop bits (a mark or a 1 bit). The result is that operating under the protocol, it is possible to transmit only 6 characters per second. As it happens, many adept typists among TDD communicators are readily able to type at rates significantly in excess of 6 characters per second. While modern microprocessor-based TDDs are capable of buffering such adept typists, the result is that the transfer of communication from one TDD terminal to another can, at times, be significantly delayed behind a fast typist. This has been a source of frustration to users in the TDD community for some time.
Another difficulty with conventional TDDs operating under Baudot/Weitbrecht protocols has to do with the fact that communication is defined to be simplex, meaning that only one station is capable of communicating at any one time. Since both transmitting and receiving stations utilize the same signals (1400 hertz for a mark and 1800 hertz for a space) on the telephone line, both stations cannot send data at the same time and also receive data. There is no provision for avoiding such collisions in the conventional Baudot/Weitbrecht protocol. Instead, prior machines are simply designed to prioritize data sending. The devices will transmit a character if a key is pressed, and if the device is sending, no attempt is made to receive data.
Nevertheless, there is a large installed base of TDDs in use in many parts of the world, including the United States. If a new protocol is intended to be implemented within the existing network of TDD users, it advantageously should be compatible with the network of existing TDDs and TDD-compatible devices. In other words, even if a terminal is capable of operating with an enhanced TDD protocol permitting pseudo-duplex capability and higher speed, a terminal must also be capable of communicating with conventional Baudot/Weitbrecht TDD terminals which have neither of those capabilities.
Finally, any protocol intended for use principally with TDD networks should advantageously be designed for conversation-like communication between people. Some communication protocols notably the American Standard Code for Information Interchange (ASCII), are specifically intended and designed to permit communications between automated devices, such as computers. However, in considering optimum protocols for TDD communications, a different set of constraints is appropriate. It is also highly desirable that all code selection be automatic, i.e., that the user not be required to set any communication protocols in order to communicate with another similarly equipped user. If a device is capable of operating at an enhanced rate of speed, or with an enhanced character set, it should switch into such operation without need for action or instructions by the user. To the extent the enhanced TDD protocol is capable of making the user's interaction with another user more akin to normal human conversation, the more the device will be appreciated and utilized in the field. Also, since there are a large number of TDDs in use in the community, to the extent that a system for enhancing communication capability can be designed which can be retrofit into existing TDDs, this will facilitate the introduction and availability of this technology to a more wide spread audience.